Adaptable computing architecture

ABSTRACT

A computing architecture. In one embodiment, the computing architecture includes a kernel that contains data and instructions in one or more database tables. A first mechanism selectively executes instructions stored in the one or more database tables to instantiate one or more objects or wrappers to encapsulate one or more computing resources. In a more specific embodiment, the one or more database tables are verticalized and include one or more atomic fields. The first mechanism further includes a second mechanism for encapsulating the kernel within an object that provides a layer of abstraction between the kernel and the one or more objects, which are coupled thereto.

CLAIM OF PRIORITY

This application claims priority from U.S. Provisional PatentApplication Ser. No. 60/847,129 filed on Sep. 26, 2006, attorney docketNo. 100154-000100US, entitled “META-OPERATIONS INFRASTRUCTURE SYSTEM”which is hereby incorporated by reference as if set forth in thisapplication in full for all purposes.

BACKGROUND OF THE INVENTION

This disclosure relates generally to computing architectures and morespecifically relates to digital processing hardware and softwarearchitectures and methods for organizing and accessing data in computersystems.

Architectures for facilitating computing are employed in variousdemanding applications including database design, data center design,parallel processing systems, Artificial Intelligence (AI), gaming,enterprise design, educational research, online communityimplementation, distributed processing systems, such as Service OrientedArchitectures (SOAs), and so on. Such applications often demand robustflexible architectures that can readily accommodate changes, includingthe addition of computing resources.

Computing architectures capable of accommodating changes areparticularly important in enterprise or business applications, whichoften require frequent changes to computing environments. Unfortunately,conventional computing architectures must often be redesigned orreconfigured to accommodate changes in underlying data structures. Inaddition, such architectures often lack effective mechanisms orstructures to readily accommodate legacy systems. Consequently, changesto computing environments using such conventional architectures oftennecessitate costly modifications, which may include replacing computingresources, such as software applications and accompanying computers.This may undesirably limit computing environment evolution.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an example embodiment of a computing architectureemploying an underlying data architecture.

FIG. 2 is a diagram of an alternative embodiment based on the exampleembodiment of FIG. 1, which illustrates certain graphical components ofa modeling language.

FIG. 3 is an illustrative embodiment based on the example embodiment ofFIG. 1 and adapted to run on a Relational DataBase Management System(RDBMS) and to selectively instantiate a relational database.

FIG. 4 is a flow diagram of a first example method that is suitable foruse with the embodiments of FIGS. 1-3.

FIG. 5 is a flow diagram of a second example method that is suitable foruse with the embodiments of FIGS. 1-3.

FIG. 6 illustrates a first part of table entries and informationaccording to an embodiment of the invention.

FIG. 7 illustrates a second part of table entries and informationaccording to an embodiment of the invention.

FIG. 8 illustrates a third part of table entries and informationaccording to an embodiment of the invention.

FIG. 9 illustrates a fourth part of table entries and informationaccording to an embodiment of the invention.

FIG. 10 illustrates a fifth part of table entries and informationaccording to an embodiment of the invention.

FIG. 11 illustrates a sixth part of table entries and informationaccording to an embodiment of the invention.

FIG. 12 illustrates a seventh part of table entries and informationaccording to an embodiment of the invention.

FIG. 13 is an illustrative embodiment #900 based on the exampleembodiment 50 of FIG. 2 and illustrates the recursively coupled tablesadapted to provide relational object services (e.g., relational object:service, or relational object service,) embodiment 64 utilizing threepointer ID fields (e.g., Obj.ID, Meth.ID, Sub.ID) within the tablerelational object 58 embodiment and the table atomic array 60, 62embodiments utilizing the array object model 54, 56 embodiments and theframework 61 embodiment

FIG. 14 is a further illustrative embodiment #950 of embodiments 200,300, 400, 500, 600, 700, 800 from FIG. 6,7,8,9,10,11,12 based on theexample embodiments 16, 18 of FIG. 1 and illustrates the recursiveprocess flow for creating a service class kernel object with therecursively coupled tables 22, 24 embodiments, (e.g., Table I, TableII).

FIG. 15 is a further illustrative embodiment #960 of embodiments 200,300, 400, 500, 600, 700, 800, 950 from FIG. 6,7,8,9,10,11,12,14 based onthe example embodiments 16, 18 of FIG. 1 and illustrates the recursiveprocess flow for creating a database class object with the recursivelycoupled tables 22, 24 embodiments, (e.g., Table I, Table II).

FIG. 16 is a further illustrative embodiment #970 of embodiments 200,300, 400, 500, 600, 700, 800, 950, 960 from FIG. 6,7,8,9,10,11,12,14,15based on the example embodiments 16, 18 of FIG. 1 and illustrates therecursive process flow for creating a database table class object withthe recursively coupled tables 22, 24 embodiments, (e.g., Table I, TableII).

FIG. 17 is a further illustrative embodiment #960 of embodiments 200,300, 400, 500, 600, 700, 800, 950 from FIG. 6,7,8,9,10,11,12,15 based onthe example embodiments 16, 18 of FIG. 1 and illustrates the recursiveprocess flow for creating a database table rows class object with therecursively coupled tables 22, 24 embodiments, (e.g., Table I, TableII).

FIG. 18 is an illustrative embodiment #1000 based on the exampleembodiment 12, 14 16, 18 of FIG. 1, embodiment 50 of FIG. 2 andillustrates the recursively coupled tables adapted to provide relationalobject services (e.g., relational object: service, or relational objectservice) relational object services encapsulation for a dynamicapplication service device and a dynamic architecture service device(e.g., Dynamic Architecture Services, Dynamic Architecture: ServiceDevice:).

FIG. 19 is an illustrative embodiment #1100 based on the exampleembodiment 12, 14 16, 18 of FIG. 1, embodiment 50 of FIG. 2, embodiment1000 of FIG. 18 and illustrates the recursively coupled tables adaptedto provide virtual model relational object services (e.g., relationalobject: service, or relational object service) encapsulation for adynamic application service device and a dynamic architecture servicedevice (e.g., Dynamic Application Service Device:, and DynamicArchitecture: Service Device:).

FIG. 20 is an illustrative embodiment #1200 based on the exampleembodiment 12, 14 16, 18 of FIG. 1, embodiment 50 of FIG. 2, embodiment1000 of FIG. 18, and embodiment 1100 of FIG. 19 and illustrates therecursively coupled tables adapted to provide virtual framework servicesencapsulation services (e.g., virtual framework: dynamic architecture:service device) encapsulation for virtual infrastructure services (e.g.,virtual infrastructure: dynamic systems: service device, or virtualinfrastructure: dynamic services: service device).

FIG. 21 is an illustrative embodiment #1300 based on the exampleembodiment 10, 16, 18 of FIG. 1, embodiment 50 of FIG. 2, embodiment1000 of FIG. 18, and embodiment 1100 of FIG. 19 and embodiment 1200 ofFIG. 20 adapted to a Artificial Intelligence, Dynamic Learning,Self-Constructing, Adaptable Simulation Machine

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

An example computing architecture includes a kernel containing data,including instructions, in one or more database tables. A firstmechanism selectively executes instructions stored in the one or moredatabase tables to instantiate one or more objects or wrappers toencapsulate one or more computing resources.

In a more specific embodiment, the one or more database tables areverticalized and include one or more atomic fields. A second mechanismencapsulates the kernel within an object that provides a layer ofabstraction between the kernel and the one or more additional objects,which are coupled thereto.

In an illustrative embodiment, the one or more database tables include afirst table and a second table. The first table includes a first set offields, wherein each field is associated with a predetermined object.The first table further includes a second set of fields that associateeach predetermined object with a type. The second table is recursivelycoupled to the first table and includes a third set of fields. Eachfield of the third set of fields is a type that can be referenced by atype ID of the first table. A fourth set of fields included in thesecond table include additional information pertaining to eachpredetermined object.

For the purposes of the present discussion, a first table is said to berecursively coupled to a second table if the first table includes one ormore keys, pointers, or other references to the second table, and thesecond table includes one or more keys, pointers, or other references tothe first table.

In the specific embodiment, the first table and the second table areencapsulated within an object. An object may be any computing entitythat is adapted to behave in a predetermined or standardized way, suchas by receiving data from other objects, processing data, and sendingdata to other objects. Certain objects may provide a layer ofabstraction between the contents of the objects and entities incommunication with the objects.

A data manager manages data and instructions in the first table and thesecond table. The data manager operates based on instructions stored inthe first table and/or the second table. In the specific embodiment, thefirst table and the second table are implemented via a verticalizeddatabase that includes one or more objects. A vertical database includesdata such as entries or objects that are associated with other datapredominantly by using references such as pointers, identificationvalues (IDs), object hierarchies, etc. This is different from ahorizontal database where the data relationships are predominantlydefined by fixed data structures stored within the RDBMS, such as adatabase having tables, and tables having records, and records havingfields, whereby in order to change data relationships the databasestructure definitions may have to be changed.

One aspect of the present invention uses a vertical object database as apersistent representation of data. However, standard database queriescan be made on the data by translating all or a needed part of theobject database into a horizontal relational database format at or priorto a time of responding to a query. The object database format can allowefficient modification of data relationships while the relationaldatabase format can provide intuitive, standardized and fast responsesto database queries.

In a particular embodiment, data is maintained in the vertical objectdatabase and the database is translated to a horizontal relationaldatabase format at periodic intervals, such as once per day. Betweentranslation intervals, the relational database can be queried usingstandard database query languages and techniques. Modifications to thedata and database format are performed to the object database and areavailable in the relational database format after the next translation.

In another embodiment, the translation can be dynamic—that is, occurringat a time of, and in response to, a query on particular data. Only therelational database structures that are needed to respond to the queryneed to be translated. The translated data can be virtual and transient,such as only residing for a brief time in solid state memory, or it canbe made more persistent such as by storing to a hard drive andmaintained for multiple queries or multiple operations, as desired.

In general, the vertical database can be implemented in any suitabledesign. However, a preferred embodiment of a specific type of verticaldatabase is described that uses a two-table approach. Many features ofthe two-table approach are described that may be adapted to otherdesigns and operations, as desired.

A preferred embodiment is generally described with respect to a standarddatabase query language called Structured Query Language (SQL). However,other suitable query languages or approaches may be used. Data may beincorporated within a Relational DataBase Management System (RDBMS).Objects in the database may include various types of data, includingdata used to execute methods, including various applications, such asservices.

For the purposes of the present discussion, a method may be any computeror processor instructions adapted to perform an action, such as adata-read, write, compile program code, install operating system, orother operation. An atomic field may be any field, node, array element,record, and so on, that can only be changed by a process that completes.A process acting on an atomic field is said to either commit, i.e.complete its operations on the field, or abort. If the process aborts,the field remains unchanged. This property may enhance robust qualitiesof an underlying data structure, thereby preventing or reducing datacorruption. A process acting on an atomic field is said to beimplementing an atomic process. To modify an atomic field, an atomicprocess may make a copy of the field and then replace the previous fieldfrom which the copied field was copied only if the process commits.

Certain operations on an atomic object may be classified as reading,writing, or deleting. An operation or atomic process that modifies anatomic object, such as an atomic field, may be called a writer, andother processes may be called readers. A reader may acquire a read lockon the atomic object to be read. Similarly, a writer may acquire a writelock on an atomic object. Such locks may be maintained until the givenprocess commits or aborts. After an atomic process either completesreading, writing, or aborting, the associated lock is released, allowingother processes to occur. Atomic actions may be nested and may beassociated with sub-locks.

The novel design of certain embodiments discussed herein is facilitatedby use of a central data model that employs verticalizedrecursively-coupled tables that store dynamic objects. The dynamicobjects may include encapsulated executable instructions or methods thatare included within an object, such as via a container or other layer ofabstraction. In addition, the verticalized recursively-coupled tablesthemselves are encapsulated within an object. By reducing reliance uponstatic data structures and by encapsulating various architecturecomponents, such as legacy systems, in a layer of abstraction, theresulting architecture can readily adapt and evolve to meet the needs ofa given application.

For the purposes of the present discussion, a layer of abstraction maybe a container, shell, or other interface for encapsulating or otherwisefacilitating use of the entity around or over which the layer ofabstraction is disposed. For example, the C programming language is saidto be separated from processor operations via layers of abstraction,which include machine language. Machine language may be considered atype of interface between processor operations and C programming code.An abstraction may also be considered a generalization of a model,algorithm, or other entity, away from a specific implementation of themodel, algorithm, or other entity.

Certain embodiments discussed herein address a growing need forenterprise meta-database systems, operational data storage systems, anddata warehouse systems, that can combine disparate data stored innon-similar structures in non-similar formats from disparate sources inheterogeneous environments. Certain embodiments discussed herein providea computing architecture and accompanying infrastructure capable ofautomatically adapting to changes in data structures and/or deviceswithout requiring extensive manual coding changes.

For clarity, various well-known components, such as power supplies,computer networking cards, compilers, operating systems, InternetService Providers (ISPs), firewalls, anti-hacking tools, and so on, havebeen omitted from the figures. However, those skilled in the art withaccess to the present teachings will know which components and featuresto implement and how to implement them to meet the needs of a givenapplication.

FIG. 1 is a diagram illustrating an example computing architecture 10.The computing architecture includes a first container 12, whichrepresents an object or layer of abstraction that encapsulates aninfrastructure object 14. Additional encapsulation layers, also calledlevels of abstraction, may be included between the infrastructure object14 and the container 12 without departing from the scope of the presentteachings.

The infrastructure object 14 encapsulates a manager 16, whichencapsulates or otherwise controls or manages a kernel object 20. Forillustrative purposes, the manager 16 is shown coupled to services 18,which are also incorporated within the infrastructure object 14. Whilethe services 18 are depicted separately from the manager 16, inpractice, the services 18 may be incorporated with the objectrepresented by the manager 16. The services 18 represent aninstantiation or virtualization derived from data stored in the kernelobject 20.

The kernel object 20 includes a first table 22 and a second table 24.The first table 22 is encapsulated as a relational object. The secondtable 24 represents an object that encapsulates one or more atomicarrays.

For the purposes of the present discussion, a table may be anycollection of organized data units. The organized data units may befields, records, nodes, data points, array elements, and so on. Hence,an array, such as an array commonly used in the C-programming language,is considered to be a type of table.

A database may be any structured collection of records or data that isstored via coding constructs. A coding construct may be any structure,such as a field or table, implemented via machine-readable instructionsor codes.

The first table 22, which may be implemented via a relational object,includes a first object-identification column 26 and a firsttype-identification column 28. For the purposes of the presentdiscussion, a relational object may be any object that includes one ormore tables or is otherwise based upon one or more tables.

The second table 24, which may be implemented via one or more atomicarrays, includes a second type-identification field 30 and a secondinformation column 32. For the purposes of the present discussion, anatomic array may be any table or other organization of data whereassociated elements, fields, nodes, records, or other components areatomic, as defined, above.

For illustrative purposes, the first object-identification column 26 isshown including several object identifications (e.g., Obj. 1, Obj. 2,Obj. 3, etc.). The object identifications in column 26 may representpointers to other objects in other tables, such as the second table 24.In addition, each object identification in column 26 is associated witha corresponding type-identification pointer (e.g., Ptr. 1, Ptr. 2, Ptr.3, etc.) in the adjacent type-identification column 28. Thetype-identification pointers 28 may point to corresponding pointers inthe second type-identification column 30 of the second table 24. Notethat reference to specific data structures such as pointers is only forpurposes of illustration unless otherwise noted. Such data structures ormechanisms may typically also be implemented by other means such as withan index, ID, membership in an array, object, etc. as is known in theart.

The second information column 32 includes additional informationassociated with a given object identified in the firstobject-identification column 26. The additional information may includeadditional object definitions, method code for implementing a service,and/or one or more additional pointers that reference one or moreobjects identified by the first table 22. For illustrative purposes, thefirst pointer (Ptr. 1) in the first type-identification column 28 pointsto the corresponding pointer (Ptr. 1) in the second type-identificationcolumn 30, which associates the first object identification (Obj. 1)with additional information (Info. 1). The additional information (Info.1) includes pointers back to the first object (Obj. 1) and the secondobject (Obj. 2) in the first object-identification column 26. The firsttable 22 is said to be recursively coupled to the second table 24, asthe tables 22, 24 reference each other via pointers, which may also becalled database keys in certain implementations.

While in the present specific embodiment, each table column 26-32 isshown including a single column of fields, each column 26-32 may includeone or more additional columns without departing from the scope of thepresent teachings. The tables 22-24 represent recursively coupledverticalized tables.

The object 20 containing the tables 22, 24 is also called an objectmodel or a kernel of an object-relational model. All data, includingexecutable instructions for methods, that is employed by thearchitecture 10 may be stored via the object 20 or via one or moreinstantiations of the object 20.

The manager 16, also called the Data Model Manager, includes methods forimplementing data-management services for managing data in the tables22, 24. In the present specific embodiment, the manager includesinstructions, which are stored via the tables 22, 24, for instantiatingthe services 18. Executable code or instruction for instantiating theservices 18 is also stored in the encapsulated tables 22, 24. Services18 may include meta-services, wherein a meta-service manages or operateson another service. In addition, the services 18 themselves areencapsulated within an object, which may be written as “RelationalObject: Service” where the use of a colon indicates that the Service isa function or method that is a property of the Relational Object. Inaddition, the “Relational Object: Service” may be referred to herein as“Relational Object Service” and should be understood to have the samemeaning. In general, variations on object, structure, properties,hierarchies and other data organization may vary from the specificembodiments shown herein and yet remain within the scope of theinvention unless otherwise noted.

For illustrative purposes, the services 18 are shown including aconstructors object 34, which is adapted to selectively instantiateencapsulated dynamic systems, virtual device constructors, and so on.The constructors object 34 and the dynamic systems object 36 are bothinstantiated from the tables 22, 24 and are encapsulated within one ormore objects. The tables 22, 24 may be encapsulated via one or moreobject containers, and the containers themselves may also beinstantiated from the tables 22, 24 in the object model 20.

For the purposes of the present discussion, dynamic systems may be anyservices that are adapted to change in nature as needed for a particularapplication. A virtual device constructor may be any computer codeadapted to construct a virtual instance of another entity, such as adevice.

A virtual instance of a device may be a software entity that is adaptedto behave similarly to the device or that is otherwise adapted tofacilitate interfacing a given device with another device or entity. Forexample, a given hardware device may employ different virtual instancesto facilitate communicating with different applications that use thedevice.

Virtualization may refer to the abstraction of computing resources, suchas via encapsulation. Virtualization may also refer to a technique forhiding physical characteristics of a computing resource from othersystems or applications interacting with the resource, such as viacreation of a special interface. For example, virtualization may beemployed to make a given single physical resource, such as a server,compiler, operating system, application, or storage device, appear tofunction as multiple logical resources. Alternatively, multiple physicalor logical resources may be virtualized to appear as a single logicalresource. Virtualization technologies often hide technical details of acomputing resource via encapsulation or other mechanisms.

While each of the tables 22, 24 are shown including two columns, eachtable 22, 24 may include more than two columns without departing fromthe scope of the present teachings. Furthermore, the first table 22 andthe second table 24 may be concatenated into a single table. Theresulting combined table is considered a super table that includessub-tables.

The computing architecture 10 may be considered an architecture thatincludes a first object 20 defining a first table 22, wherein the firsttable includes one or more pointers 28. A second table 24 communicateswith the first table 22, wherein the one or more pointers 28 in thefirst table 22 reference information 32 in the second table 24. In aspecific implementation, the information 32 includes a method 16 forinstantiating one or more additional objects 18, wherein data componentsof the one or more additional objects are stored via the first table 22and the second table 24 or instances thereof. The second table 24includes one or more atomic fields 32.

Alternatively, the computing architecture 10 may be considered anarchitecture that includes a first table object 22 with a first column26 for identifying one or more objects, and a second column 28 foraccessing or invoking additional information 32 associated with each ofthe one or more objects 26. In a specific implementation, the additionalinformation 32 includes a method. The first column 26 includes one ormore object identification pointers or numbers (Obj. 1, Obj. 2, Obj. 3,etc.) associated with the one or more objects. The second column 28includes one or more pointers (Ptr. 1, Ptr. 2, Ptr. 3, etc.) to a secondtable 24. The one or more pointers 28 point to an object or field (e.g.,Info. 1, Info. 2, Info. 3) in the second table 24 that points back toone or more fields (e.g., Obj. 1, Obj. 2, etc.) in the first table 22.The second table 24 includes a type table or column 30. The first table22 and the second table 24 are verticalized and include one or moreatomic fields.

The following discussion of table normalization is intended tofacilitate an understanding of benefits afforded via certain embodimentsdiscussed herein.

Certain databases store data in so-called horizontal structures. Anexample table for tracking books checked out at a library includes a rowof various horizontal fields for each book that is checked out. Examplefields include book identification, user name, address, phone number,and so on. If a user checks out multiple books, the user name, address,phone number, and so on are repeated in separate rows for each book thatis checked out. This results in undesirably redundant repetition ofdata, such as user name address, and so on, in the database.

A database manager may wish to add additional fields to the database,such as fields indicating the date on which the book was checked out,the date on which the book is due for return, and so on. When the fieldsare inserted into the horizontal structure, the rows become wider, andrelative positions of certain data in the table may change.Unfortunately, external programs, such as services, that wish to accessthe underlying table must often be changed to accommodate changes to thetable. Data stored in this way is said to be stored in a flat orhorizontal file or table. Such tables are also typically “static” inthat they are maintained and used in a single persistent structure.

To address this problem, table data may be verticalized, i.e.normalized. In the above example, different tables may be used to storebook identification information, user name, user address, and so on.Each table may have a pointer or other identification informationassociating a given field with another field in another table. In thisway, for example, when a user checks out multiple books, each book maybe associated with a pointer to the corresponding user information inanother table. This limits undesirable repetition of the userinformation.

In addition, an additional table, called a type table for the purposesof the present discussion, may be added. The type table associates eachtype of information with a first pointer or identification andassociates a second pointer with a given user. The second pointer may beassociated with the type pointer. In this way, when a databaseadministrator or manager wishes to add new fields, such as checkout andreturn dates, such fields may simply be appended to the type table alongwith a pointer to the given user, without changing the underlyingstructure or way external programs access the tables. The additionalfields and associated data are said to be provisioned. For the purposesof the present discussion, data stored in this way is said to be storedvertically or in a verticalized file or table. This facilitatesprovisioning of additional data in a table.

Similarly, certain embodiments discussed herein, including the computingarchitecture 10, may employ verticalized table structures 22, 24, alsocalled relational structures, encapsulated within one or more objects12-16, 20, to represent underlying data structures. This furtherimproves adaptability of the architecture to underlying changes in datastructures, which are implemented as objects in certain embodimentsdiscussed herein, and facilitates growth of the overall architecture 10.Hence, using the verticalized tables 22, 24 in the object 20 torepresent the data model for the computing architecture 10 enhances theability of the computing architecture to evolve and change as needed.

FIG. 2 is a diagram of an alternative embodiment of a computingarchitecture 50 based on the example embodiment 10 of FIG. 1. FIG. 2also illustrates certain example graphical components or symbols of aso-called modeling language or architecture-specification syntax.

For the purposes of the present discussion, a language may be any systemof symbols, such as graphical, written, or audible symbols, and rules toimplement them. The modeling language or specification discussed hereinrepresents a so-called semantic ontological meta-modeling language thatis employed to represent the architecture 50. The meta-modeling languageis adapted to further facilitate adaptability, growth, and generaladvancement of a computing architecture or computing environment, asdiscussed more fully below.

The computing architecture 50 includes a so-called array-object model52, which is identified by a graphical symbol 54. The array-object model52 is encapsulated within an array-object-model object 56, whichincludes a relational object 58 that is coupled to an atomic array 60.The relational object 58 is analogous to the first table 22 of FIG. 1,and the atomic array 60 is analogous to the second table 24 of FIG. 1.The relational object 58 and the atomic array 60 are implemented via aframework object 61. The framework object 61 includes one or moreentities, elements, and/or relationship components for implementingand/or instantiating the array-object model object 56 or one or moreversions thereof. The relational object services functionality 64 mayfurther facilitate implementing and/or instantiating the array-objectmodel 56. The relational object services functionality 64 may be partlyspecified by the name relational object: service or meta-services. Therelational object services functionality 64 may further provideadditional functionality or methods to facilitate using relationalobject structures, such as the relational object 58 and atomic array 60,in the array-object model 52. The atomic array object 60 may furtherinclude virtual databases stored therein. In addition, certain services,such as relational-object services may be included, identified, and/ordefined by one or more records in the relational object 58.

A data-model manager, which is identified by a first manager symbol 66and a second symbol 68, may encapsulate the array-object model 52.Alternatively, the data-model manager 66, 68 may be encapsulated withinthe array-object model 52. The data-model manager 66, 68 includesdata-management services for supporting and maintaining dynamicrelational structures within the relational-object model represented bythe array-object model object 56. Data-management services may bederived via data and instructions maintained in the relational object 58and atomic array 60. The data-model manager 66, 68, which may also bepartly specified by the name data model: manager, is also identified bya second data-model manager symbol 70.

For illustrative purposes, the atomic array 60 is shown expanded toinclude various atomic fields 62, which may also be called arrayelements, nodes, or records. Example atomic fields include an atomicidentification (ID), void, virtual, alpha numeric, numeric, binary,current date, create date, change data, and password fields. Examplefields in the relational object 58 include object ID, method ID, andsubject ID. The relational object 58 and the atomic array 62 may includeadditional pointers and fields that recursively couple certain fields inthe relational object 58 with certain fields in the atomic array 62. Forexample, object ID, method ID, and subject ID may act as pointers in therelational object 58 that refer to or point to data in the atomic array60 or in another table, which in turn references the pointers in therelational object 58. Hence, the relational object 58 is recursivelycoupled to the atomic array 60.

In addition, the relational object 58 may include other objects, such asrelational object services 64, array objects, and relational objects.Such objects may be employed to create virtual instances of otherobjects and to place containers around other resources, such asconstructors, devices, systems, and databases in a given computingenvironment.

The data-model definition, as represented by the array-object model 56,may be used to define other objects intended to act upon or be basedupon data or instructions included in the constituent relational object58 and atomic array 60.

Those skilled in the art with access to the present teachings willappreciate that the computing architecture 50 may be expanded andencapsulated in other objects without departing from the scope of thepresent teachings. In general, the computing architecture 50 is adaptedto grow into any of various forms to meet the needs of a givenapplication or implementation.

In the present embodiment, an example language may be employed toidentify objects by name, wherein the name identifies parent objects inorder. For example, an object D, which is contained within an object C,which is contained within and object B, which is contained within anobject A, may be identified as object A:B:C:D. As a more specificexample, the framework 61 may be specified by the name array-objectmodel: entity relationship model: framework. This name suggests that anentity-relationship object encapsulates the framework object 61, andthat the entity-relationship object is encapsulated by thearray-object-model object 56.

In addition, the language may incorporate certain graphical symbols,e.g., symbols 54, 64, 70, to refer to certain objects or certaincontainers of the objects. An overall architecture that incorporatesseveral objects in different hierarchical layers may be generallyspecified by a set of names identifying each object of the architecture.Such a modeling language or specification may facilitate designinghierarchical layers of abstraction in an architecture and to facilitatemanaging the overall architecture or infrastructure within a shell-likeenvironment, also called a relational-object environment.

The present example language is said to be a semantic language in thatit may be defined by the rules generating the language structures orsymbols rather than the vocabulary of primitives itself. The term“semantics” may also imply that domain knowledge is used to makesoftware more intelligent, adaptive, and efficient.

The language is said to be an ontological language in that constituentterms, names, or symbols may represent sets of relationships (asrepresented by data models) that in turn represent a certain domain. Theterm “ontology” may refer to any set of relationships, such as a set ofrelationships defining a data model that represents a “domain” and isused to reason about the objects in that domain and the relationsbetween them. For example, an ontology about animals might specify thata class “dog” is a sub-class of the class “mammal” and that classes“mammal” and “reptile” are disjoint. Similarly, a given computingobject, such as the relational object 58, may represent a class or setof relationships defining a so-called domain or grouping ofrelationships.

The language is said to be a meta-modeling language in that it may beemployed or extended to specify other symbols or languages to defineother containers or objects. For the purposes of the present discussion,a meta-modeling language may be any language used to construct a set ofconcepts or to define another language. Similarly, the computingarchitecture 50 may be considered to implement a meta-application forimplementing a high level of abstraction by encapsulating entitieswithin the architecture 50 within predetermined objects.

In the present specific embodiment, inheritance relationships betweenobjects may be bidirectional. However, different inheritancerelationships may be employed without departing from the scope of thepresent teachings.

The following analogy pertaining to Operating Systems (OSs) is intendedto facilitate an understanding of benefits afforded via certainembodiments discussed herein. Early versions of computer operatingsystems were developed almost entirely using assembly code and machinelanguage, which are considered relatively low-level programminglanguages. For example, machine language programming involves writingcomputer code in the form of binary states, such as 1s and 0s, which maybe read by a computer processor. The 1s and 0s may be representative ofhigh or low voltage states in hardware latches and flip-flops as outputby certain physical logic gates within a computer processor. Assemblylanguage programming involves writing computer code in the form ofsymbols that represent one or more groupings of 1s and 0s. Assemblylanguage is said to be a higher-level language in that it provides aso-called layer of abstraction above machine language to facilitateprogramming, also called coding. Operating systems implemented inassembly language or machine language were often relatively inflexible,since the addition of new computing resources, such as hardware, oftenrequired re-coding of the OS to accommodate the resources.

Subsequently, operating systems, such as UNIX, implemented a so-calledkernel architecture. For the purposes of the present discussion, akernel may be the central part of a system or architecture, such as anoperating system, which facilitates managing system resources andcommunications between accompanying components, such as hardware andsoftware modules.

An Operating System (OS) may be any program adapted to manage hardwareand/or software resources of a computer. A computer may be any processorin communication with a memory. An example OS may perform basiccomputing tasks, such as controlling and allocating memory, prioritizingthe processing of instructions, controlling input and output devices,facilitating networking, and managing files.

The UNIX kernel, which was originally written in assembly or machinelanguage, was encapsulated in a shell, which is a type of object. Eachshell or object provides a layer of abstraction between that which iscontained within the object and external entities, such as otherobjects.

The shell was designed to readily interface with other modules writtenin higher-level languages, such as the C programming language. Theresulting architecture increased portability and adaptability of theoperating system. Various solutions to computing problems were thenimplemented in so-called shells that could readily interface with the OSkernel and accompanying shell. The development of certain shells led tothe development of other shells, which facilitated growth of UNIX-basedcomputing environments.

Embodiments discussed herein may be employed to provide shells, calledobjects herein, around various computing entities, such as various typesof data and computing resources, not just software components or datastructures. In accordance with embodiments discussed herein, an entirearchitecture may be incorporated within an object, and sub-components ofthe architecture may themselves be represent or be contained withintheir own objects. Consistent behavioral properties of the objectsfacilitate growth and expansion of an entire computing environment. Forexample, certain architectures implemented in accordance with thepresent teachings may readily interface with other similararchitectures.

In addition, in accordance with the present teachings, legacy systems(e.g., certain chip devices or other application 40 of FIG. 1) areencapsulated within objects that are compatible with other architecturalcomponents. The objects are configured to hide or convert anyinconsistent behavior of underlying legacy systems so that the resultingbehavior of a given legacy system as seen through the encapsulatingobject is compatible with the overall architecture.

Certain embodiments discussed herein provide a kernel-likeinfrastructure and one or more abstraction layers to allow for a modularadoptive development environment that evolves with technologyinnovation, yet retains referential historical integrity of allrespective data, legacy systems, applications and infrastructures.

While certain programming languages, such as C++, have successfully usedobjects to facilitate computer programming, object concepts have yet tobe applied to an entire computing architecture that includes legacysystems, such as preexisting hardware; software components, such asservices; and the data itself. For example, conventional object orientedprogramming languages, such as C++, often continue to rely upon staticunderlying data structures that limit the ability of the resultingprograms to accommodate changes in the underlying data structures. Thismay promote the so-called impedance mismatch phenomena where objectoriented programming languages often have difficulty interfacing withdatabases or using underlying database structures as objects.Furthermore, conventional object-oriented methodologies often do noteffectively handle or support data management and data integrity issues.

By encapsulating the entire computing environment and associatedinfrastructure as one or more objects within a data-centric relationalmodel, certain embodiments discussed herein provide a missing foundationto enable current and legacy systems to co-exist and continue evolvingtoward a more cohesive operational standard and technology model.

Certain embodiments disclosed herein implement a relational-object datamodel combined with a compiler-based design to maximize adaptability andminimize any required re-coding of components within the accompanyingcomputing architecture.

Computing architectures discussed herein, such as the architectures 10and 50, of FIGS. 1 and 2, are said to exhibit a compiler-based design,since the architectures employ or implement encapsulation or act as asuch as via so-called object containers or shells. The encapsulation maybe said to perform the function of a constructor (e.g., constructorsobject 34 of FIG. 1) or service constructor, which may be further saidto perform the function of a compiler or interpreter or converter orassembler or provisioner or instantiator or translator. Theencapsulation facilitates or performs any requisite translations to makedifferent underlying processes compatible or executable. The term“compiler” as used herein refers to an entity that is adapted to performtranslation of any type. However, the term “compiler” is commonly usedspecifically to refer to a computer program that translates one type ofcomputer language to another. For example, a C-compiler may translatethe C programming language to machine language for execution by aprocessor.

Certain embodiments discussed herein are designed with the understandingthat the core of many computing environments is data, which includes thedata or instructions defining program code used to access the dataitself and which may include one or more operating systems employed bythe architecture. Computing architectures discussed herein generallyemploy a compiler-based design, wherein application aspects representdata points or collections. This facilitates dynamically loading andcompiling application code. All constituent program code, system code,or data structures may be stored via the data model and accompanyingobjects (e.g., the object 20 of FIG. 1 or the array-object model 56 ofFIG. 2).

Hence, certain embodiments discussed herein employ a design orarchitecture wherein every aspect of the application is, or can be used,as a data-point, or data-collection represented by an object. Such datapoints or collections may be employed to instantiate an instance of anapplication or system infrastructure, thereby creating a virtualenvironment that can dynamically provide, load and compile, anyapplicable system or application code. The physical devices, operatingsystems, or a compiler itself, can be provisioned to create, on demand,any working computing environment, as needed, since all of the relatedprogram code, system code, or data structures are all stored within theoverall architecture.

FIG. 3 is an illustrative embodiment 80 based on the example embodiment10 of FIG. 1 and adapted to run on a Relational-DataBase ManagementSystem (RDBMS) 82 within a relational-object server object 84. Thearchitecture 80 may be used to selectively instantiate a relationaldatabase 86, as discussed more fully below.

The RDBMS 82 includes a manager object 88, which includes a data-modelmanager 90 that governs an object model 92. The object model 92 may beimplemented via an object that is similar to object 20 of FIG. 1 or thearray-object model object 56 of FIG. 2. The manager 90 may beimplemented similarly to the manager 16 of FIG. 1 or the data-modelmanager 66, 68 of FIG. 2. The RDBMS also runs an historical database 94,which for illustrative purposes includes one more static databasestructures. The historical database 94 is encapsulated within an objectmodel object and may be instantiated via the manager 90 and object model92.

For the purposes of the present discussion, a data model or a databasemodel may be any theory or specification describing how a dataset ordatabase is structured and/or used. An object database may be anydatabase in which information is represented in the form of objects. AnObject DataBase Management System (ODBMS) may be any system for managingor controlling an object database. A database may be any collection ofdata in a structure. An RDBMS may be a database management system inwhich data is stored in the form of tables and the relationship amongthe data is also stored in the form of tables.

In operation, the manager 90 selectively employs contents of the objectmodel 92 to instantiate the real-time dynamic relational database 86.The real-time dynamic relational database 86 may be implemented via oneor more various well-known databases, such as Oracle or Microsoft SQL.Code for executing the databases may be stored in one or morerecursively coupled verticalized tables maintained in the object model92.

Instantiation of the real-time dynamic relational database 86 via themanager 90 and object model 92 may facilitate incorporating changes tounderlying data maintained via the object model 92. In certainapplications, the real-time dynamic relational database will include ahorizontal or flat file for easy or high-speed data entry and access,where the flat file is selectively verticalized or decomposed into thetables maintained via the object model 92. The decomposition ofdatabases, services, applications, and so on may be implemented viainstructions running on the manager 90 or elsewhere. Such instructionsmay be stored via the object model 92.

Certain object encapsulation may be temporarily removed to facilitatehigh-end performance. The resulting data and/or instructions may bemaintained via a relational database, such as the database 86. Hence,the architecture 80 demonstrates that different applications can beinstantiated from various objects arising from the kernel maintained viathe object model 92 and accompanying manager 90. After modifications aremade to the high-speed relational database 86, the resulting data may besaved in the underlying structure represented by the object model 92. Inthis case, the original encapsulated data structures are analogous to abase atomic object, while the high-speed relational database 86 isanalogous to a temporary atomic object that is operated on before theresults are saved and replace the base atomic object.

Data in the historical database 94 may be accessed via the real-timedynamic relational database 86 via one or more encapsulation containersor layers of abstraction afforded by the object model 92. This enhancescompatibility between any legacy databases implemented via thehistorical database 94 and the real-time dynamic relational database 86.

As another example, the object model 92 may incorporate, store, and/orselectively instantiate the entire specification for Structured QueryLanguage (SQL). SQL may be stored or incorporated as a method within oneor more objects within the object model 92.

In general, when data in the object model 92 is to be changed, a copy ofthe previous version is maintained until the associated services orapplications commit to completing a given process pertaining to thedata. The object model 92 is said to exhibit atomicity.

Hence, the present computing architecture 80 is based on dynamic orreadily changeable data structures rather than static data structures,also called data models. For the purposes of the present discussion, astatic data structure may be any data structure that is not adapted toreadily change its structure. For example, a static array may have afixed number of fields or elements.

A dynamic data structure may be a data structure that may readilychange, such as by adding or removing fields, rearranging relationshipsbetween fields, rearranging the organization of fields or records, andso on. A method may be any computer instruction for performing anaction. The instruction itself may be considered a type of data that maybe stored via underlying dynamic data structures discussed herein.

Dynamic data structures may be stored within a database managementsystem or file management system, such as the RDBMS 82, along withprocesses, computer calls, and object-oriented methods (software thatexecute services), that employ or operate on the underlying data andaccompanying structures.

Conventionally, any required changes to underlying static datastructures stored in the historical database 94 necessitatedcorresponding changes to processes or other databases that employed orreferenced the data structures. Use of the object model 92 and manager90 facilitate overcoming the need to change the real-time dynamicrelational database 86 to accommodate changes to the historical database94.

In addition, changes to computing infrastructure or resources, such asdevices and applications, such as services, often necessitated changesto other programming code within the overall architecture. Certainembodiments discussed herein may obviate this need.

While the computing architecture 80 is shown implemented via an RDBMS,other implementations are possible. For example, the manager object 88and accompanying data manager 90 and object model 92 may alternativelybe implemented within a data server running within a computer operatingsystem, or within code running within a computer system chip or BasicInput/Output System (BIOS), or in other environments.

FIG. 4 is a flow diagram of a first example method 100 suitable for usewith the embodiments 10, 50, 80 of FIGS. 1-3. The method 100 includes afirst step 102, which includes establishing encapsulated dynamic datastructures that underlie a computing environment or architecture. Theunderlying dynamic data structures include one or more tables to storedata and instructions. In one embodiment, the tables includeverticalized tables with one or more atomic fields.

A second step 104 includes selectively instantiating one or moredatabases, programs, or other resources via data and instructions storedin the encapsulated dynamic data structures so that the databases,programs, or other resources are encapsulated within one or moreobjects.

FIG. 5 is a flow diagram of a second example method 110 suitable for usewith the embodiments 10, 50, 80 of FIGS. 1-3. The second example method110 includes an initial step, which involves determining an initial setof resources to be initially employed in a computing architecture.

A subsequent encapsulation step 114 includes encapsulating eachcomponent of the initial set of resources within one or more objects.

Next, a creation step 116 includes creating an underlying dynamic datastructure wherein data and instructions for implementing orencapsulating said initial set of resources or objects associatedtherewith are stored.

Those skilled in the art will appreciate that more or fewer steps may beadded to the flowcharts herein without departing from the scope of theinvention. It should be apparent that steps may be reordered or modifiedand that the same functionality may be achieved, unless otherwise noted.

FIGS. 12-21 are next discussed to show more details of a specifictwo-table embodiment using the arrangement described above in thediscussion of FIG. 1. It should be apparent that various actions andmechanisms presented in connection with the two-table approach may beadapted for use with three or more tables unless otherwise noted.

FIG. 6 shows a first part 200 of Table I and II entries. Each entry inTable I is shown in a rounded square with the first field (left side)value indicating an object ID followed by a colon and the second field(right side) value indicating the type ID. Similarly, entries in TableII are illustrated using a type ID value on the left side followed by anequal sign (“=”) and a right side information description of the valuetype. For ease of illustration simple numbers or descriptions are used.It should be apparent that in an actual implementation each value can bedefined in any suitable format or structure (e.g., single or double wordinteger, floating point value, character string, pointer, array, etc.).

The example application shown in FIGS. 6-12 uses a typical relationalobject database kernel shell encapsulation service. Kernel object 202 isshown providing encapsulation for services and members 204 whichprovides recursive encapsulation for services constructors 206 whichprovides encapsulation for members services such as “Members-Service”208. Encapsulation is illustrated in the Figures by using a backgroundpattern of radiating lines and/or by using heavy-lined box borders.However, it should be apparent that other types of database designs maybe used where the specific types of encapsulation illustrated in thisexample are not always employed.

For illustrative purposes, the kernel object, Object:Kernel 202, isshown providing encapsulation class membership for owner object,Owner:object 210, with recursive object shell members (e.g., 10:11,10:12, 10:13, 11:3, 12:6, 13:7). In other embodiments, any number ofadditional members may be included. For ease of illustration, only oneor a few example entries or other items are presented.

Object:Kernel 202 provides encapsulation class membership for database,table, column, column display, rows, record and field objects. Eachinstance of these types of objects (and objects generally presentedherein) are referred to by a naming convention such as the followingwhich correspond to the types listed in the prior sentence:Database:object 212; Table:object 214; Column:object 216;Column-Display:object 218; Rows:object 220; Record:object 222 andField:object 224.

Each object instance may have having recursive object shell memberswhich are entries in Table I as shown in FIG. 6. For example,Database:object 212 includes member entries 14:11, 14:15, 14:16, 15:3,16:6 and 17:7.

Encapsulation can include encapsulation hierarchies. For example,Database:object 212 is shown encapsulating Table:object 214.Table:object 214 is shown providing encapsulation for Column:object 216,and so on, as indicated by the heavy-lined bounding boxes.

Table II information entries are shown at 250 a and 250 b. In entries at250 a several encapsulation service class objects are defined as0=“KERNEL”, 1=“Object”, 2=“Services”, 3=“Members”, 4=“Constructors”,5=“Services-Script:, 6=“Members-Service:, 7=“Constructors-Service:,10=“Owner”, 11=“Owner-Member”. These pairs of “type ID=information”correspond to the fields 30 and 32 of Table II 24 in FIG. 1. and areused to define encapsulations of services 18, constructors 34 anddynamic systems 36 of FIG. 1. The number and type of such services orobjects and the manner of encapsulations may vary in differentembodiments.

Table II entries at 250 b defines typical encapsulation database classobjects as 12=“Member-Script,: <select . . . ”, 13=“Constructor-Script:<select . . . ”, 14=“Database”, 15=“Database-Member”, 16=“Member-Script:<select . . . , 17=“Constructor-Script: <select . . . ”. These are usedto provide further encapsulation for services 18, which can be used toprovide further encapsulation for constructors 34, dynamic systems 36,etc. Note that in a particular embodiment, services are dynamic and canbe created, deleted or modified.

FIG. 7 shows a second part 300 of table entries and information used inconjunction with table entries of first part 200 to illustrate asimplified database service for portion of a medical records database toillustrate embodiments of the invention.

Kernel object 302 is shown providing encapsulation class membership forowner object 310, database object container 312, table object container314, column object container 316, column display object container 318,rows object 320, record object container 322 and field object container324.

Owner object, Owner:object 310, provides encapsulation class membershipfor DB Owner:owner 330 having entry 99:10 and encapsulating MedicalDB:database 331 having entries 100:99 and 100:14. DB Owner object DBOwner:object 330 is shown providing encapsulation class membership forPatient-TB:table 332.

Patient-TB:table 332 also encapsulates other objects such as Name column334, Age column 336, Phone column 338, each of which providesencapsulation for column display 344, 346 and 348, respectively. Forillustrative purposes, the Patient TB Rows, (e.g., Patient-TB0-Rows:rows350) is shown providing encapsulation for rows 360, 370 and 380, whicheach in turn, provide further encapsulation for members 362, 364, 366,372, 374, 376, 382, 384, and 386.

FIG. 8 shows a third part 400 of table entries and informationstructures relating to table parts 200 and 300 from FIGS. 6 and 7, basedon the example 16, 18 of FIG. 1 and illustrates the recursively coupledtables 22, 24 adapted to run a relational object database service for aMedical DB with a Patient Table with rows with Name, Age, and Phoneinformation recursively stored.

For illustrative purposes, table object container 414 is shown providingencapsulation class membership for Patient TB 432 and 432 a. Patient-TBmembers provide encapsulation members (e.g., Name, Age, Phone) in 434,436, and 438, which in turn, each provide encapsulation members (e.g.,String, Age, “( )-” (representing a phone number format)) in 444, 446,and 448.

Patient-TB-Rows members 432 a is shown providing encapsulation members(e.g., Patient-TB-Row 1, Patient-TB-Row2, Patient-TB-Row3) in 460, 470,480, which in turn, each provide encapsulation members 462, 464, 466,462, 464, 466, 462, 464, and 466.

For illustrative purposes, the Patient-TB-Rows object members 432 a(ID=120) are shown to inherit Patient-TB 432 (ID=101) object members,wherein specifically, member 434, 444 are inherited by 434 a, 434 b, and434 c, and 436, 446 are inherited by 436 a, 436 b, and 436 c, and 438,448 are inherited by 438 a, 438 b, and 438 c.

Note that the services 400 a, 400 b, 400 c, 400 d are meant as anillustrative example of the changing nature of all encapsulatedservices.

FIG. 9 shows a fourth part 500 of table entries and information adaptedwith typical service owner, service member and service constructorobjects. For illustrative purposes, the table info (e.g., “Table II”)550 is shown with encapsulation service class objects, (e.g.,Object:Kernel 560, Object:owner 570, Object:member 580,Object:constructor 590. In this example, table info 580 contains thefollowing executable script to traverse the recursive objects for thisservice: ID: 12=“Member-Script: <select [Object-ID] from [Object-Table]where [Type-ID]=[‘Owner-Member’ ]>”. Such script can be written in SQLor any other suitable language. The script provides functionality toperform the three primary relational database functions of insert,update, and deletion. Any other type of functionality may be provided inother embodiments.

Note that object kernel 502 and its recursive members have the samecharacteristics and properties of object kernels represented in 202, 302in FIGS. 6,7. Note that the services, object:services,object:owner:services, object:member:services,object:constructor:services, owner:services, member:services, andconstructor:services, and other services are merely examples toillustrate a particular application of an embodiment of the invention.

FIG. 10 shows a fifth part of table entries and information adapted withtypical database owner, database member and database constructorobjects. For illustrative purposes, the table info (e.g., “Table II”)650 is shown with database owner 670, database member 680 and databaseconstructor objects 690. ID=17, includes the following executable scriptto traverse the recursive objects for this service: ID:16=“Member-Script: <select [Object-ID] from [Object-Table] where[Type-ID]=[‘Database-Member’ ]>”. The script provides functionality toperform the three primary relational database functions of insert,update, and deletion. Any other suitable database service class objectsmay be used in other applications.

Note that in a particular embodiment the object kernel 602, and all ofits recursive members, have the same characteristics and properties ofobject kernels 202, 302 in FIGS. 6 and 7. For example, the databaseobject 602 is identical to the database objects 212 and 312 in FIGS. 6and 7.

Note that the services, object:services, object:owner:services, object:member: services, object:constructor: services, owner: services, member:services, and constructor:services, represented in 600 a, 660 a, 670 a,680 a, 690 a, 670 b, 680 b, and 690 b are meant as an illustrativeexample of encapsulated services.

FIG. 11 shows a sixth part 700 of table entries and information adaptedwith typical table, column, and column-display service class objects.For illustrative purposes, the table info (e.g., “Table II”) 750 isshown with typical table, column, and column-display service classobjects, 714, 716, 718 respectively, each of which include, owner,member, and constructor class objects 770 a, 780 a, 790 a, 770 b, 780 b,790 b, 770 c, 780 c, and 790 c respectively. Database object container712, and all of its recursive members have the same characteristics andproperties of database objects and database object containers 212, 312,612 in FIGS. 6,7 and 10.

FIG. 12 shows a seventh part 800 of table entries and informationadapted with typical rows, record, and field service class objects. Forillustrative purposes, the table info (e.g., “Table II”) 850 is shownwith rows, record, and field, service class objects, 820, 822, 824respectively, each of which include, owner, member, and constructorclass objects 870 a, 880 a, 890 a, 870 b, 880 b, 890 b, 870 c, 880 c,and 890 c respectively. Table object container 814, and all of itsrecursive members have the same characteristics and properties of tableobjects and table object containers 214, 314, 412 in FIGS. 6, 7 and 8.

The kernel object service is used to retrieve relational databases andtables in an exemplary manner as follows:

To display the patient phone number for a particular patient from thepatient TB table from the medical DB database, a SQL command is executedthat is passed as a parameter to the kernel and the kernel thendetermines if the current instantiation of the medical database has thecurrent active data and structures, if the current instantiation ofmedical database has the active records, then the kernel routes the SQLcommand directly to the RDBMS for execution. If the currentinstantiation of the medical database does not have the current activedata and structures, or if there is no instantiation of the medicaldatabase, then the kernel dynamically generates the medical database.The kernel dynamically generates the medical database by recursivelyretrieving the medical database object records and executing therelevant constructor service scripts which reconstructs the medicaldatabase and table structures and provides either a typical relationaldatabase view or by dynamically creating an instance of the database onthe RDBMS server with typical SQL table create and table insertcommands.

If the process is creating a new instance of the database, the kernelprocess first retrieves object and constructor records for a databaseobject, which it uses to create a virtual instance of the databases,which it uses to map to the database members, which contains thedatabase Medical DB. The kernel then retrieves object and constructorrecords for table object, which it uses to create a virtual instance ofthe tables, which it uses to map to the table members, which containsthe table patient-TB. The kernel then retrieves object and constructorrecords for table rows, which it uses to create a virtual instance ofthe patient TB table rows, which it uses to create an instance on theRDBMS platform, to construct a typical SQL view. The kernel alsoexecutes the relevant object constructor services, which in the case ofthe patient table, includes a table column display object, which willprovide the service of converting the phone string of 2125551212, intothe display format of “(###)-###-####” as specified by the objectservice method, resulting in the output of the phone number as“(212)-555-1212”.

The object-ID, type-id, in tables I, II (22, 24 embodiments in FIG. 1)are used to retrieve objects in an exemplary manner as follows:

Object-ID is first used to retrieve database object components, whichexists as Type-ID child records (28 embodiment in FIG. 7) in table I (22embodiment in FIG. 1), and are mapped to Info fields (32 embodiment) inTable II (24 embodiments in FIG. 1). The process then executes theconstructor scripts, which exist in the info fields that are indicatedby the Type-ID records. This process involves getting all of the memberrecords, and all records for which the object is a member. This involvestraversing the object table (Table I) in both directions. For example,the Medical DB object (#ID=100) (331 embodiment in FIG. 7) is used todetermine which objects are members of it by searching for all objectswith a Type-ID (#ID=100), which returns the Patient-TB (332 embodimentin FIG. 7) object (e.g., #ID=101, (101:100)). The process thendetermines that Patient-TB object (#ID=101) is a table object byretrieving from object table (Table I) all Type-ID that have object-IDof Patient-TB object (#ID=101), which retrieves table object container314 embodiment in FIG. 7 (e.g., #ID=18, (101:18) a (18:1))). The processthen retrieves all members of Patient-TB object (#ID=101), by retrievingall objects with a Patient-TB object (#ID=101) as the Type-ID, whichretrieves column object (334,336,338 embodiments in FIG. 7) (e.g.,#ID=102, 103, 104 à (102:101), (103:101) (104:101)), and Patient-TB-Rowsobject (350 embodiment in FIG. 7) (#ID=120). The column objects(#ID=102, 103, 104) contain the column headings (e.g., Name, Age,Phone). The process then retrieves all members of column objects(#ID=102, 103, 104), by retrieving all objects with a column object(#ID=102, 103, 104) (#ID=101) as the Type-ID, which retrieves columndisplay objects (344, 346, 348 embodiments in FIG. 7) (e.g., #ID=110,111, 112 à (110:102), (111:103) (112:101)), which contain the columndisplay methods, (e.g., string, int, “(###)###-####”).

The process then retrieves all objects that are members ofPatient-TB-Rows object (#ID=120) (350 embodiments in FIG. 7), byretrieving all objects with a Patient-TB-Rows object (#ID=120) as theType-ID, which retrieves Patient-TB-Row1, Patient-TB-Row2,Patient-TB-Row3, (360, 370, 380 embodiments in FIG. 7) (e.g., #ID=1001,1005, 1009 a (1001:120), (1005:120) (1001:120)). The process thenretrieves all objects that are members of Patient-TB-Row1,Patient-TB-Row2, Patient-TB-Row3, (e.g., #ID=1001, 1005, 1009), byretrieving all objects with a Patient-TB-Row1, Patient-TB-Row2, orPatient-TB-Row3 as Type-ID, which retrieves Patient-TB-Row1,2,3 Fieldobjects, (362, 364, 366, 372, 374, 376, 382, 384, 386 embodiments inFIG. 7), (e.g., #ID=1002, 1003, 1004, 1006, 1007, 1008, 1010, 1011, 1012à (1002:1001), (1003:1001), (1004:1001), (1006:1005), (1007:1005),(1008:1005), (1010:1009), (1011:1009), (1012:1009). The process thenretrieves all objects that are members of Patient-TB-Row1,2,3 Fieldobjects, by retrieving all objects with a Patient-TB-Row1,2,3 Fieldobjects as Type-ID, which retrieves, the so called, Patient-TB-Row1,2,3Field content objects, (362 a, 364 a, 366 a, 372 a, 374 a, 376 a, 382 a,384 a, 386 a embodiments in FIG. 8), (e.g., # 1013, 1014, 1015, 1016,1017, 1018, 1019, 1020, 1021 à (1013:1002), (1014:1003), (1015:1004),(1016:1006), (1017:1007), (1018:1008), (1019:1010), (1020:1011),(1021:1012), which contain the field contents, which it displays usingthe respective column display methods, (e.g., Joe Smith, 40,(212)555-1212, Tom Stevens, 30, (212)444-1212, Susan Adams, 20,(213)333-1212.).

For illustrative purposes, the table 905 of FIG. 13 includes relationalobject services 64 recursively mapped within the array object model 54,56 utilizing the three ID fields, Object 910, Method 920 and Subject930, corresponding to Obj.ID, Meth.ID, Sub.ID of relational object 58 inFIG. 2. The Object, Method and Subject (e.g., Obj.ID, Meth.ID, Sub.ID)are used to retrieve objects in an exemplary manner as follows:

The Object for database is used to retrieve database methods andsubjects, wherein a database method will indicate that the object is adatabase, and that it has database methods, some of which are table andcolumn structures and names, as well as the methods for retrieving thetable row data. The methods provide the member scripts to access thetables and retrieve data from them. The method subjects provide methodidentifiers, like table name and column names. The process thenrecursively applies the subject table name and subject column name(e.g., Sub.ID) as Objects (e.g, Obj.ID) joined back to the to theRelational Object Table (relational object 58 of FIG. 2.), whichretrieves all methods and subjects associated with each table and columnobject. The methods provide table and column structure, as well asaccess and display formats and procedures, and method subjects willprovide the row field contents, like Name=“Joe Smith”, Age=40, and PhoneNumber=(212) 555-1212. Those skilled in the art with access to thepresent teachings may readily design and implement other suitablerelational object services.

FIG. 13 shows relational object services 900 based on architecture 50 ofFIG. 2 and illustrates the recursively coupled tables adapted to providerelational object services (e.g., relational object: service, orrelational object service,) 64 utilizing three pointer ID fields (e.g.,Obj.ID, Meth.ID, Sub.ID) within the table relational object

FIG. 14 illustrates a flow diagram for creation of a service classobject and illustrates the recursive process flow for creating a serviceclass kernel object with the recursively coupled tables 22, 24 of FIG.1.

FIG. 15 illustrates a flow diagram 960 for creating a database classobject with the recursively coupled tables.

FIG. 16 illustrates is a flow diagram 970 for a recursive process flowfor creating a database table class object with the recursively coupledtables.

FIG. 17 illustrates a flow diagram is a further illustrative embodiment980 for creating a database table rows class object with the recursivelycoupled tables.

FIG. 18 shows diagram 1000 based on the architecture of FIGS. 1 and 2and illustrates the recursively coupled tables adapted to providerelational object services (e.g., relational object: service, orrelational object service) encapsulation for a dynamic applicationservice device and a dynamic architecture service device (e.g., DynamicApplication: Service Device:, and Dynamic Architecture: ServiceDevice:).

FIG. 19 shows diagram 1100 based on the architecture of FIGS. 1 and 2and illustrates the recursively coupled tables adapted to providevirtual model relational object services (e.g., relational object:service, or relational object service) encapsulation for a dynamicapplication service device and a dynamic architecture service device(e.g., Dynamic Application Service Device:, and Dynamic Architecture:Service Device:).

FIG. 20 shows diagram 1200 based on the architecture of FIGS. 1 and 2and the diagrams of FIGS. 18 and 19 and illustrates the recursivelycoupled tables adapted to provide virtual framework servicesencapsulation services (e.g., virtual framework: dynamic architecture:service device) encapsulation for virtual infrastructure services (e.g.,virtual infrastructure: dynamic systems: service device, or virtualinfrastructure dynamic services: service device).

FIG. 21 shows diagram 1300 to describe a general architecture for anartificial intelligence machine that incorporates aspects of theinvention described herein. In FIG. 21, five basic services are used tocreate an object hierarchy to achieve a dynamic learning,self-constructing, adaptable simulation machine. These services includerelational 1310, architecture 1320, information 1330, infrastructure1340 and device 1350 services. These services are arranged in ahierarchy so that object-oriented principles such as encapsulation,inheritance and polymorphism, etc., may be applied.

The field of Artificial intelligence (or AI), includes “the study anddesign of intelligent agents” where an intelligent agent is a systemthat perceives its environment and takes actions which maximizes itschances of success. Other names for the field have been proposed, suchas computational intelligence, synthetic intelligence or computationalrationality. It involves an iterative development or learning processfor pattern recognition for condition matching, built around automatedinference engines including forward reasoning and backwards reasoning.An intelligent, or learning machine, is said to be adaptable, in allways. This requires complete recursive thought and processing ofinformation. It must be able to allow for the rise and fall ofrelational information structures, architectural models, and physicaldevices within a seamless array of interruptible tasks.

One of the early AI inventions of the implementation of a simulation ofthe “Game of Life”—a cellular automaton discovered by the mathematicianJohn Conway. The Life field is a grid of square cells, each of which canbe either “on” (colored in) or “off” (background color) at any giventime. You can think of this as meaning that the colored cells are“alive”, while the grey ones are “dead”. The fate of each cell in thenext instant depends on how many of its eight immediate neighbors(including those along the diagonals) are alive in the precedinginstant. The rules of Life can be very simply summed up in three simplerules: (1.) cells that have exactly 3 living neighbors at one instantwill be “on” in the next instant; (2.) cells that have exactly 2 livingneighbors at one instant will stay as they are in the next instant; (3.)cells with any other number of living neighbours at one instant willturn “off” the next instant.

The life game is defined by the rules associated with the relationshipbetween neighboring cells. With this in mind, the study of AI systemsmust also follow a pattern inherent to biological systems withinanimals, humans, and all life in general. In humans, the Cerebral cortexis said to be one the most critical and “intelligent” components of thebrain stem, it stores memories. The Cerebral cortex stores all memory ofall sensory input at the cellular level in identical ways, whether it isauditory, sensory, visually, etc. Even imagined stimulation asinformation is received and managed at the cellular level with theidentical core building blocks. It is a relational machine. It relatesand correlates. Research has shown that the brain demonstrates the bestability to recall information if it is recalled through a linearsequence of events. It can be said that the relationship of a linearsequence of time is the easiest to recall because it is the type ofrelationship that one is most familiar. This is because the cellularstructures within the Cerebral cortex have had ample time learn thistype of relationship, the relationship called sequence. The types ofRelationships that are known to be valid are the easiest to recallbecause of the frame of reference, by virtue of the relationship tosomething know. This is the core of any learning entity. It is thedefining and interrogating of relationships.

The challenge of AI is not one of increasingly complexity, but rather,it is one of simplicity. As is evident in Albert Einstein how's unendingsearch for a grand unifying theory, the intellect is ever searching todefine relationships that unify objects. A relationship object is themost basic and atomic component that comprises and serves as thebuilding blocks of intelligence.

The analogy of building a house will illustrate the usefulness andapplicability of these five components.

The design of an architecture includes recursively identifying all ofthe component pieces necessary to construct the house, i.e., therelationships between objects. A strut, a nail, a roof, etc, are alldefined in how they relate to each other, as well as, how they relate tothe physics of what is a soundly engineered house.

An architect must recursively design a visual model of the house.

This owner of the house must recursively consider multiple architecturemodels and evaluate which is the optimal model and what is the optimallocation for the house.

The owner must contract a general contractor, who must recursivelysecure all of the necessary provisions and personnel in order to buildthe infrastructure of the house.

The general contractor and the work crew must recursively build all ofthe component structural devices that comprise the house.

This analogy to building a house can be used to describe the process bywhich a robotics learning machine must be able to store dynamicallychanging relationships in order to deal with the physical world. Arobotic machine must be able to correctly relate a visual depiction of aobject, like a piece of wood, with its internal memory database of whatwood is. A robotics machine must also be able to create dynamicarchitectural models of the world in order to navigate through roughterrain, or cross a river. A robotics machine must be able to analyzeprevious and forward thinking architectures, relationship,infrastructures, and building arrangements in order to make criticaldecisions about an action or activity. A robotics machine must also beable to provide provisioning infrastructure mechanisms to fix a problemwithin its own hardware or software, or to build a new piece of hardwareor software. And lastly, the robotics machine must be able to build newdevices. This is most evident in nano technologies andField-programmable gate array wherein new devices, or new chip sets,must be constructed dynamically.

While certain embodiments disclosed herein are discussed with respect toproviding a new adaptable computing architecture for certainapplications, embodiments of the present invention are not limited andmay be applicable to any computing infrastructure. For the purposes ofthe present discussion, an infrastructure may be any set ofinterconnected structural elements that provide the framework supportingan entire structure.

In general, any suitable programming language can be used to implementfeatures of the present invention including, e.g., C, C++, Java, PL/I,assembly language, etc. Different programming techniques can be employedsuch as procedural or object oriented. The routines can execute on asingle processing device or multiple processors. The order of operationsdescribed herein can be changed. Multiple steps can be performed at thesame time. Flowchart sequences can be interrupted. The routines canoperate in an operating system environment or as stand-alone routinesoccupying all, or a substantial part, of the system processing.

Steps can be performed by hardware or software, as desired. Note thatsteps can be added to, taken from or modified from the steps in theflowcharts presented in this specification without deviating from thescope of the invention. In general, the flowcharts are only used toindicate one possible sequence of basic operations to achieve afunction.

In the description herein, numerous specific details are provided, suchas examples of components and/or methods, to provide a thoroughunderstanding of embodiments of the present invention. One skilled inthe relevant art will recognize, however, that an embodiment of theinvention can be practiced without one or more of the specific details,or with other apparatus, systems, assemblies, methods, components,materials, parts, and/or the like. In other instances, well-knownstructures, materials, or operations are not specifically shown ordescribed in detail to avoid obscuring aspects of embodiments of thepresent invention.

As used herein, the various databases, application software or networktools may reside in one or more server computers and more particularly,in the memory of such server computers. As used herein, “memory” forpurposes of embodiments of the present invention may be any medium thatcan contain, store, communicate, propagate, or transport the program foruse by or in connection with the instruction execution system,apparatus, system or device. The memory can be, by way of example onlybut not by limitation, an electronic, magnetic, optical,electromagnetic, infrared, or semiconductor system, apparatus, system,device, propagation medium, or computer memory.

A “processor” or “process” includes any human, hardware and/or softwaresystem, mechanism or component that processes data, signals or otherinformation. A processor can include a system with a general-purposecentral processing unit, multiple processing units, dedicated circuitryfor achieving functionality, or other systems. Processing need not belimited to a geographic location, or have temporal limitations. Forexample, a processor can perform its functions in “real time,”“offline,” in a “batch mode,” etc. Portions of processing can beperformed at different times and at different locations, by different(or the same) processing systems.

Reference throughout this specification to “one embodiment,” “anembodiment,” or “a specific embodiment” means that a particular feature,structure, or characteristic described in connection with the embodimentis included in at least one embodiment of the present invention and notnecessarily in all embodiments. Thus, respective appearances of thephrases “in one embodiment,” “in an embodiment,” or “in a specificembodiment” in various places throughout this specification are notnecessarily referring to the same embodiment. Furthermore, theparticular features, structures, or characteristics of any specificembodiment of the present invention may be combined in any suitablemanner with one or more other embodiments. It is to be understood thatother variations and modifications of the embodiments of the presentinvention described and illustrated herein are possible in light of theteachings herein and are to be considered as part of the spirit andscope of the present invention.

Embodiments of the invention may be implemented by using a programmedgeneral purpose digital computer, by using application specificintegrated circuits, programmable logic devices, field programmable gatearrays, optical, chemical, biological, quantum or nanoengineeredsystems, components and mechanisms may be used. In general, thefunctions of the present invention can be achieved by any means as isknown in the art. Distributed or networked systems, components andcircuits can be used. Communication, or transfer, of data may be wired,wireless, or by any other means.

It will also be appreciated that one or more of the elements depicted inthe drawings/figures can also be implemented in a more separated orintegrated manner, or even removed or rendered as inoperable in certaincases, as is useful in accordance with a particular application. It isalso within the spirit and scope of the present invention to implement aprogram or code that can be stored in a machine readable medium topermit a computer to perform any of the methods described above.

Additionally, any signal arrows in the drawings/Figures should beconsidered only as exemplary, and not limiting, unless otherwisespecifically noted. Furthermore, the term “or” as used herein isgenerally intended to mean “and/or” unless otherwise indicated. Inaddition, the term “includes” as used herein is intended to mean“includes, but is not limited to” unless otherwise indicated.Combinations of components or steps will also be considered as beingnoted, where terminology is foreseen as rendering the ability toseparate or combine is unclear.

As used in the description herein and throughout the claims that follow,“a,” “an,” and “the” includes plural references unless the contextclearly dictates otherwise. Also, as used in the description herein andthroughout the claims that follow, the meaning of “in” includes “in” and“on” unless the context clearly dictates otherwise.

The foregoing description of illustrated embodiments of the presentinvention, including what is described in the Abstract, is not intendedto be exhaustive or to limit the invention to the precise formsdisclosed herein. While specific embodiments of, and examples for, theinvention are described herein for illustrative purposes only, variousequivalent modifications are possible within the spirit and scope of thepresent invention, as those skilled in the relevant art will recognizeand appreciate. As indicated, these modifications may be made to thepresent invention in light of the foregoing description of illustratedembodiments of the present invention and are to be included within thespirit and scope of the present invention.

Thus, while the present invention has been described herein withreference to particular embodiments thereof, a latitude of modification,various changes and substitutions are intended in the foregoingdisclosures, and it will be appreciated that in some instances somefeatures of embodiments of the invention will be employed without acorresponding use of other features without departing from the scope andspirit of the invention as set forth. Therefore, many modifications maybe made to adapt a particular situation or material to the essentialscope and spirit of the present invention. It is intended that theinvention not be limited to the particular terms used in followingclaims and/or to the particular embodiment disclosed as the best modecontemplated for carrying out this invention, but that the inventionwill include any and all embodiments and equivalents falling within thescope of the appended claims.

1. A method for handling a database query, wherein a first databaseincludes first data arranged in an object-oriented format, the methodcomprising: receiving a relational database query; translating at leasta portion of the first data from the object-oriented format to seconddata in a second database, wherein the second data is arranged in arelational database format; and using the second data to provide aresponse to the relational database query.
 2. The method of claim 1,wherein translating comprises: translating the at least a portion of thedata at a time prior to receiving the relational database query.
 3. Themethod of claim 2, further comprising: performing scheduled translationsof the first data to the second data; storing the second data in apersistent machine-readable medium for database operations during apredetermined interval of time; and updating the first data by using thedatabase operations prior to a next translation of the first data to thesecond data.
 4. The method of claim 1, wherein translating comprises:translating the at least a portion of the data at a time of receivingthe relational database query.
 5. The method of claim 4, wherein thesecond data is maintained in transient memory.
 6. A computingarchitecture comprising: a first object defining a first table thatincludes one or more pointers; and a second table in communication withthe first table, wherein the one or more pointers reference informationin the second table.
 7. The computing architecture of claim 6, whereinthe information includes: a method adapted to instantiate one or moreadditional objects, wherein data components of the one or moreadditional objects are stored via the first table and the second tableor instances thereof.
 8. The computing architecture of claim 7, whereinthe second table includes one or more atomic fields.
 9. A computingarchitecture comprising: a first table object including: a first columnfor identifying one or more objects; a second column for accessing orinvoking additional information associated with each of the one or moreobjects.
 10. The computing architecture of claim 9, wherein theadditional information includes: a method.
 11. The computingarchitecture of claim 10, wherein the first column includes: one or moreobject identification pointers or numbers associated with the one ormore objects.
 12. The computing architecture of claim 11, wherein thesecond column includes: one or more pointers to a second table.
 13. Thecomputing architecture of claim 12, wherein the one or more pointerspoint to an object or field in the second table that points back to oneor more fields in the first table.
 14. The computing architecture ofclaim 13, wherein the second table includes: a type table.
 15. Thecomputing architecture of claim 12, wherein the first table and thesecond table are verticalized and include: one or more atomic fields.16. A method for implementing computing architecture comprising:determining an initial set of resources to be initially employed in thecomputing architecture; encapsulating each component of the initial setof resources within one or more objects; and creating an underlyingdynamic data structure wherein data and instructions for implementing orencapsulating the initial set of resources or objects associatedtherewith are stored.
 17. The method of claim 16, further including:encapsulating the underlying dynamic data structure within a firstobject.
 18. The method of claim 17, wherein the first object includes: arelational object.
 19. The method of claim 18, wherein the relationalobject includes: a table that includes atomic fields.
 20. The method ofclaim 18, wherein the relational object further includes: a second tablethat is recursively coupled to the first table.
 21. A computingarchitecture comprising: a set of resources, wherein each resource isencapsulated within one or more objects; and a data structure includingone or more dynamic data structures for storing data and instructionspertaining to the one or more objects or resources.
 22. The computingarchitecture of claim 21, wherein the one or more dynamic datastructures include: one or more verticalized database tables.
 23. Thecomputing architecture of claim 21, wherein the one or more dynamic datastructures represent a data model upon which the architecture is based,and wherein the one or more dynamic data structures are encapsulatedwithin an object.
 24. The computing architecture of claim 23, whereinthe object includes: a relational object.
 25. The computing architectureof claim 24, wherein the relational object includes: a first table and asecond table.
 26. The computing architecture of claim 25, wherein thefirst table includes: one or more atomic fields.
 27. The computingarchitecture of claim 25, wherein the second table includes: one or moreatomic fields.
 28. The computing architecture of claim 25, wherein thefirst table includes: one or more pointers to one or more fields in thesecond table. 28-A. The computing architecture of claim 25, wherein thesecond table includes: one or more pointers to one or more fields in thefirst table.
 29. The computing architecture of claim 21, wherein everycomponent of the computing architecture is incorporated within an objector otherwise separated from other computing resources via a layer ofabstraction.
 30. A computing architecture comprising: a first tableincluding: a first set of fields each associated with a predeterminedobject; and a second set of fields associating each predetermined objectwith a type; and a second table recursively coupled to the first table,wherein the second table includes: a third set of fields, where eachfield of the third set of fields is associated with one or more fieldsof the first set of fields; and a fourth set of fields, where each fieldof the fourth set of fields includes additional information pertainingto each predetermined object.
 31. The computing architecture of claim30, wherein the first table and the second table are encapsulated withinan object.
 32. The computing architecture of claim 31, furtherincluding: a manager adapted to manage data and instructions in thefirst table and the second table, and wherein the manager includesinstructions stored in one or more of the first table and the secondtable.
 33. The computing architecture of claim 30, wherein the first setof fields and the second set of fields are atomic fields.
 34. Thecomputing architecture of claim 30, wherein the first table includes: arelational object.
 35. The computing architecture of claim 34, whereinthe second table includes: an atomic array.
 36. The computingarchitecture of claim 30, wherein the first table and the second tableimplement a data definition for defining one or more objects.
 37. Thecomputing architecture of claim 36, wherein the one or more objectsinclude an object adapted to manipulate the first table and/or thesecond table.
 38. The computing architecture of claim 30, wherein thepredetermined object includes a first method object.
 39. The computingarchitecture of claim 38, wherein the first method object is adapted toinstantiate one or more additional objects defined via the first tableand the second table.
 40. The computing architecture of claim 39,wherein the first method object is adapted to selectively instantiate arelational database from the first table and the second table.
 41. Thecomputing architecture of claim 40, wherein the first method object isadapted to save data represented via the relational database via thefirst table and second table.
 42. The computing architecture of claim30, wherein the predetermined object includes: a second method, whereinthe second method is adapted to encapsulate a static data structure viaan object that includes the first table and the second table.
 43. Thecomputing architecture of claim 30, wherein the predetermined objectincludes an object that encapsulates the first table and the secondtable.
 44. The computing architecture of claim 30, wherein the firsttable and the second table are implemented via a verticalized databasethat includes one or more objects.
 45. The computing architecture ofclaim 44, wherein a specification for Structured Query Language (SQL) isincorporated as a method within the one or more objects.
 46. Thecomputing architecture of claim 45, wherein the one or more objects areincorporated within a Remote DataBase Management System (RDBMS).
 47. Amethod for designing an artificial intelligence system, the method usinga digital processor to execute the following actions: using anobject-oriented hierarchy of services as follows: using a relationalservice that is encapsulated by an architecture service; using thearchitecture service that is encapsulated by an information service;using the information service that is encapsulated by an infrastructureservice; using the infrastructure service that is encapsulated by adevice service; and using the device service.
 48. The method of claim47, wherein the artificial intelligence system is adapted to themanagement of multi-core processors to support dynamic coupling anddecoupling of services.
 49. The method of claim 47, wherein theartificial intelligence system is adapted to design of afield-programmable gate array (FPGA), wherein a new FPGA is constructeddynamically.
 50. The method of claim 47, wherein the artificialintelligence system is adapted to a robotics learning machine, themethod further comprising: stores dynamically changing relationshipsabout the physical world; and processing the relationships in order todetermine a robotic behavior.